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From the GM’s Desk: 





In the past month or two, we have seen th ntire scenario change three 
times as far as Atari is concerned. Of these changes Atari can be held 
directly responsible for two and therefore be given the credit for having 
made the changes. 





The Dram situation is not the fault of Atari but you can be sure they are 
not sitting still over this matter....Jack Tramiel has been in Washington 
D.C. (The Hill) attempting to "enlighten" a few of our uninformed 
legislators....GOOD LUCK TO YOU SIR! 








The other changes are sure to, in the future, be a veritable golden bonus 
to the users but for now are rather painful and aggravating to put up 
with. My hope is that both Atari and the UserBase (Us Too!) can tolerate 
the inconveniences and clumsiness closely associated with the total, in 
the field, reorganisation we are witnessing. 


The time is at hand for all parties concerned to maintain level heads and 
cool tempers ....we all are aware that an emotional statement will roll on 
for what seems to be an eternity and produce nothing but more hard 
feelings and personal attacks this must come to a screeching halt. 





We at ST Report are dedicated to forthright information without the 


pressure of any IOUs and when we see what we feel is either hurting Atari 
or it’s users we will indeed make what we find known to all. The Flip 
side of the coin is treated the same way We shall report fully and 
completely all positive matter that effect either Atari and/or the 
Userbase. 





As of this issue, we will strive to point out to the readers as many of 
the positive items we can find. Some have asked; why do we reprint 
certain things we find on the major services? The answer is simple, many 
of the folks who eventually get to read ST Report have no modem... 
therefore, everything we have here is "new" to them. We are now 

opening an extended hand and asking for reader submitted articles. We 
hope to see full participation by all. Reader Submissions maybe U/Led to 














any of the services attached to E-Mail or, sent to ST Report via FNET NODE 








# 350. 


R.F.MARIANO 
Gen’1 Mgr. APEInc. 











THE "NEW" TOS 











AUG/88 


TOS ROM set, configured for local keyboard and American text. 
Diskette (D/S) containing: 


RAM loadable image of TOS, same configuration as ROM 
Disk cache program "CACHExxx" 
HDX Hard Disk utility, HINSTALL and associated programs 
Product Tracking System front-end program "SPRgen" 
Release Notes for: 

TOS 

CACHEXXxX 

HDX, HINSTALL etc (modified to 30/60MB hard disks) 
Draft User Manual for HDX, HINSTALL etc. 
User guide for Product Tracking System 
Various programs, files and tools to assist in translation 














Each subsidiary has been invited to select a small set of Beta sites, 
and has been requested to ensure that each such site accepts, in 
writing, certain terms and conditions, including: 





No copies to be made. 














Products and documentation are prerelease and without warranty 
All communications are to be made solely to the Atari 
subsidiary, and not through public channels. 

All] copies and documentation to be returned to Atari 
subsidiary on demand. 

Weekly report indicating name(s) of tester(s), tests performed, 


observations to be filed with Atari subsidiary each Friday. 
Any bug reports to be first verified against the currently 
released hardware/firmware, to ensure problem is with new TOS. 
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and so I would appreciate your NOT disrupting 


to continue at optimum speed. 


We have support groups in place, 
be your first line of support if development of new products 





A summary of the major improvements to TOS follows: 


Floppy formatting is 
A file may be moved 


(i.e. 


copy/delete) 


and they 
is 


"more compatible" with IBM-PC format. 
in one operation. 


File Copy/Delete/Move can be interrupted with "undo". 





If 
all 





owed. 


GEM programs can be autobooted from disk. 
a name conflict occurs during a file copy, 


Copy/ 


A folder may be renamed via "Show Info". 
The static file allocation limit of 400 is removed; 
by free memory. 




















Skip/Quit are 


limited now 


























"Show/Print File" are completely rewritten. 
File copying on a single floppy system uses all available memory 
for buffers. 
"wind_update (FALSE)" is set when recovering from an application 
crash. 
All date separators are now "/". 
File Selector has had major rework: 
16 drive buttons. 
Application can send a "title" string to FSEL. 
FSEL now takes first <RETURN> on pathname edit as end-of-edit. 
Static file allocation of 100 files is removed. 
Long pathnames and "ABORT/CONTINUE" now handled correctly. 
Preserves current DTA buffer addresses, clip rectangles and 
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default directories. 
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ws 512 vertices 


returns version 0130 in global(0). 
Editable fields may now be followed by non-editable characters in 
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urns address/ 


(true since 4/22/87). 
Pixel errors on some 270 degree rotations are fixed 


"vq_mouse" reliability enhanced. 

40-folder bug alleviated to the point of improbability. A folder 
only takes up space when "active". Limited now by depth of 
folders and the accumulated depth of open files. FOLDRxxx still 
available. 

"Malloc" restriction of 20 blocks/process lifted. 

FAT searching code for floppy and hard-disk is MUCH faster. 
Sector buffering greatly improved, and "CACHEXxx" allows 
expansion. 

"Frename" can now rename a folder. 

Archive bit (0x20) fully supported. 

Time stamps for "." and ".." are now correct. 

"Fsettime/Fsetdate" match BIOS and GEMDOS values 

"Fdatime" input value byteswap fixed 

Major improvements to "Ccon*" and redirection in general 

OS Pool reduced to same size as 11/20/85 ROMs (pre Mega). This 
may allow some programs which fail on Mega ROMs to work again. 
Soft Reset available from Keyboard if using standard keyboard 
handler. 

Soft reset by CTRL/ALT/DEL. 

Cold Boot clears all available memory (CTRL/ALT/right SHFT/DEL). 
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"RSGonti-2y7 1h): sL,4b;<1,-1) returns last baud rate value set by 
Rsconf. 

Structure of the reserved part of DTA has changed, and remains 
reserved. 


Improvements made to detection of media change. 
































THE ABOVE IS A SUBSET OF THE ENHANCEMENTS MADE. THERE ARE MANY MOR 
FULLY DOCUMENTED IN THE RELEASE NOTES SENT TO EACH SUBSIDIARY. 
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Roy J. Good 

Product Development, Atari Corporation 

Views expressed are my own. Atari may agree or disagree; they have the 
right. 
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FOR A LIMITED TIME ONLY 
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COMPUSERVE WILL PRESENT $15.00 WORTH OF COMPLIMENTARY ONLIN 
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to the Readers 











ST REPORT ONLINE ELECTRONIC MAGAZIN 
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NEW USERS SIGN UP TODAY! 





Call any of the St Report Official BBS numbers 
(Listed at the top of ST REPORT) 

or 

Leave E-mail to St Report, Ron Kovacs or Rex Reade 

















Be sure to include your full mailing address so your 
Compuserve kit can be immediately mailed to you! 


Expires 09-30-88 
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SPECIAL SUPRA MODEM OFFER!!! 




















CompuServe’s Atari Forums have made very special arrangements with 
Paramount Products Inc. to offer the members of our forums the chance to 
upgrade your system to 2400 baud service at a very special price. 


For a limited time, CompuServe subscribers may purchase the 


SUPRA CORP. 2400 baud Hayes-compatible modem 
for the very **LOW** price of just $139.95 !!!!! 


These are brand new, not reconditioned units, with the full SUPRA CORP. 
warranty. The SUPRA MODEM uses the Hayes Smartmodem 'AT’ command set and 
operates at 300-1200-2400 baud. It’s an outboard unit (not an internal 
plug-in card) allowing ease of transfer to other computers. 

Connection is thru the standard RS-232 interface. (Just plug it into the 
back of your ATARI ST). 





To take advantage of this special offer, Phone the 800 number 
listed below or write to: 





Paramount Products Inc. 
1405 S.E. Pacific Blvd. 
Albany, Oregon 97321 





FAKER Phone orders: (800)444-4061 KERER 
Price: $139.95 + shipping 
UPS ground: add $4.00 
UPS Blue label: add $8.00 
GeO Dun add $2.25 


MasterCard or VISA accepted Orders will be shipped the next business day 


If you’ve been accessing CompuServe at 1200 baud, this is a great way 
to lower your total online bill since CIS does *NOT* charge a premium for 
2400 baud access. (You can get the same amount of information or download 
the same amount of programs in approximately 1/2 the time as 1200 baud 
users!) This modem will PAY FOR ITSELF in just a few sessions. 











BOOTSTRAP —- A SECOND LOOK 











The Sequel 


by M. Arthur 


After writing STSUPORT, (the original name of the essay) I realized that 


I made a few errors which, though minor, ARE serious enough to require 
a clarification. 





I am glad the article appeared in ST REPORT, however I feel this note is 
needed because ST REPORT is usually under tight scrutiny by Knowledgable 
ST Users from a wide and diversified readership. I do not wish the few 
errors in the essay criticizing Atari to become an excuse for dismissing 
it as "Atari Bashing", I would hope this clears up any errors in the 
article: BOOTSTRAPPING ATARI. 











And Now: 

1) The Timex Sinclair Spectrum QL (not to be confused with the OTHER 
Timex Sinclairs) wasn’t AS FAST as the ST, but was, in many areas, faster 
or equally as fast as the Amiga. 





2) As known by most ST users, the number of colors in each resolution of 
the ST are the most possible to use while not slowing down the 68000. 











While this DOES come in handy, there ARE times when many colors 

are needed (Spectrum 512?), and when slowing down the processor chip as a 
result is NOT important. This is when the "Extended Resolutions" could be 
useful. 

















For those unfamiliar with the Extended Color Resolution specs requested, 
they are: A 512 color Low Resolution, and a 16 Color Medium Resolution, 
(Like EGA?) out of a palette of 4096 colors if possible, and 16 Shade 

gray scaling for High Resolution. This would be an "Extended" Color Mode 
available as options like EXTENDED LOW, EXTENDED MEDIUM, and EXTENDED HIGH 
RESOLUTION, so the current ST Resolutions would be standard, but that ST 
Users/Developers wanting better graphics could use any Extended 
Resolution. 










































































This idea SHOULD be done in HARDWARE, as software solutions to problems 
like this, which usually emulate the preferred feature, like PC Ditto for 
IBM Emulation, or Spectrum 512, have been slower than if they were done 
in hardware. And NOT EVERYONE can spend 3000-4000 dollars ,has the time 
to learn UNIX or, the skill needed to make applications for Atari’s 68030 


























Machine to obtain superior graphics. Contrary to beliefs of a few, having 
LOTS of colors has also become a fact of life for microcomputers. 
(EGA, VGA, Mac II, Amiga for examples) 





If Atari R&D (or the Tramiels) is wary of this idea, ALL they need do is 
incorporate the Trio routines into the MMU chips and coupled with TOS 
support having 512 colors at the same time WON’T take up 80-90% of 
processor time. Which is what Atari WANTED to keep from happening to ST 
displays, wasn’t it? 








3) A quote, from BOOTSTRAPPNG ATARI: 


"There is no reason why Atari could not come out with a Mega board with 
the Motorola 68851 MMU chip providing the functions of a TRUE MMU, such as 
memory paging for virtual memory, this would make TOS support of all the 
68000 address space easier. Perhaps selling it through DEALERS along with 
the new ROMs is a way to go. Fact is, using the MMU chip for other 
purposes, would definately be improving the ST’s capabilities in the 
process." No other logical reason except that the 68000 chip cannot 
support MMUs of this type, OR hardware memory protection, making use of 

a 68851 impossible. 

















But.. the 68020, which has been neglected by TOS, Does support the 68851. 
Thereby making hardware memory protection, and bomb-free multitasking, 
possible. MT C-SHELL, while a good ST multitasker, is not bomb free, 
because of the use of the 68000, and while being reliable, isn’t that 
foolproof, just as Multifinder isn’t. IF Atari would cause TOS to 
support the 68020 we would have true multi tasking 











Along with Mac II emulation, if the 68020 ST were to have an expansion 
card making the ST meet Mac II resolution and use a 20-25 MHZ 68020 
along with an optional hardware "box" that had 2-6 NuBus (Mac II board 
type) slots. 











4) Another quote which isn’t QUITE true: 
"the Mac II, which is..not powerful enough, except in the area of speed" 


I meant to edit this before I sent it anywhere, but it slipped by. The 
Mac II is the BEST in some areas of computing, having super graphics and 
a good design, except for it’s speed, which it isn’t as good. Atari’s 
68030 UNIX machine ought to be its main competition, if it doesn’t become 
vapor. 





5) The comments relating to piracy are about the ST being perceived as 

the segment of computers having the most pirates. Perhaps this is a 

very logical conclusion. When one compares the number of machines in use 
to the number of the number of pirates that have been caught. However, 
this is a deceptive impression. The amount of machines in use is in 
question, some say 225,00 others say 400,000+, we are inclined to go 

with the higher number, since certain program sales would show this figure 





to be more accurate.... Ratio and proportion would dictate that the more 
machines in use, the more pirates...True, but consider this, the more 
machines in use...the more sales recorded for new releases. This is the 








fly in the ointment; Each and every Atari ST owner could buy a copy of 
a new release and a version of it released in the IBM or MAC market would 
casually out sell it! 








COUPLED with erratic product supply and the lack of advertising, can 


anyone expect the publishers and developers for the ST market to be 
bubbling over with enthusiasm and high expectations? Just ask ’em about 
the developer’s kit. 


The above comments and corrections were supplied by the Author of the 
article, A KEEN OBSERVATION..... BOOTSTRAPPING ATARI, Micheal Arthur. We 
thank him for his candor and sincere attempts for real accuracy. 




















"A little caution outflanks a large cavalry" 
- Bismarck - 











TOP UPLOADER CONTEST! ! 











Beginning September 3,1988 till October 3, 1988 











Tst PRIZE ee p aa ayaa 5 hours of Genie connect time non-prime time 
2NA PRIZE e a Ea 3 hours of Genie connect time non-prime time 
BEGUPREAB Se Stes, b dudes 2 hours of Genie connect time non-prime time 
RULES 





Prizes will be credited to ones account when winners are announced shortly 
after October 3,1988. 


We will be awarding 3 prizes for: The MOST files uploaded. 
Pictures and song files are excluded 
also non-functioning slideshows. 


Duplicates will not be counted. 


Advertising/and or text files are also excluded. 














Remember uploading is FREE at 300/1200/2400 baud during non-primetime. 
Get those files to us and win. Besides the prizes, sharing feels good... 
doesn’t it?? <smile> 


Darlah J <Hudson> Pine 
Atari Sysop 


























A DAY AT THE RACES 











After three years of research and development we are proud 
to announce "A Day at the Races". It was designed and 
written by Marshall Lake and Piet Francke and is being 
distributed by TEAM Software. 


"A Day at the Races" is a simulation of the horse race 
track environment. Much more than the horse race itself, 
this simulation allows you to buy and sell horses, choose 
jockeys, and of course wager on races. Each horse and jockey 
have their own distinct attributes and abilities which affect 
the outcome of each race. Just like at a real track it is up 
to you to discern which abilities each horse and jockey 
possess and to attempt to pick the probable winner of the 
race. It is as close to the real world of horse racing as 
you can get without going to the track. The actual horse 
race itself is presented in exciting, nail-biting real time. 
Dynamic data base files are kept for the horses and the jockeys. 
All the various statistical items (including horses’ past 
performances) are maintained to assist in an intelligent wager, 
horse purchase, or jockey selection. "A Day at the Races" is 
a multi or single player game. 























This simulation was designed specifically for the Atari ST 
line of microcomputers. There is nothing like it available 
for ANY other microcomputer today that we are aware of! 


Knowledge of horses or the race track is not necessary 
at all to enjoy "A Day at the Races". The simulation is 
presented in such a manner as to make it easy for all users 
to understand. Depth is combined with simplicity to create a 
real-world environment which can b njoyed by everyon 
whether or not they are race track aficionados. 








"A Day at the Races" operates in the GEM environment, is 
entirely mouse controlled, and makes full use of the ST’s 
superb graphics and sound. 


The simulation requires 512K of RAM with TOS in ROM, at 
least 1 disk drive, and a color monitor. Optional equipment 
include a second disk drive and a printer. "A Day at the 
Races" IS installable onto a hard disk drive. Using a 
printer, you may obtain hard copy output of the Racing 
Program, the Racing Form, the Cheat Sheet, various standings, 
and many other statistics that are available. You will, 
of course, be able to view these items on the screen, also. 


This program will be available by October 15, 1988. 


TEAM Software 
P. O. Box 7332 





Washington, D. C. 20044 
(703) 533-2132 
(603) 679-1211 
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Please send any comments to MLAKE. 





THE TRANSPUTER 








Captured from the ST-Report area on The Source. (PARTI) 
(Atari Users Group) 


Subject - Atari’s new transputer 


From: anc@camcon.uucp (Adrian Cockcroft) 

Newsgroups: comp.sys.transputer,comp.sys.amiga,comp.sys.atari.st 
Subject: Atari/Perihelion Transputer Machine Spec 

Keywords: transputer atari workstation 

Message-ID: <986@titan.camcon.uucp> 

Date: 15 Oct 87 13:37:21 GMT 

Organization: Cambridge Consultants Ltd., Cambridge, UK 

Lines: 176 


There have been rumours about Atari and Transputers circulating so I 
thought that I had better get some hard information out there. I have no 
involvement in Perihelion, neither has my employer although I have been 
aware of events at Perihelion and know some of the people who work there. 
I do want one of their workstations however, I rate it as better than a 
SUN 3/260Ct+fpa for numbercrunching with a single T800. 


A presentation was given by Atari and Perihelion at the Cafe Royal in 
London on 22/9/87, over 100 software developers, hardware manufacturers 
and press people attended and no restrictions were made on the information 
presented at the meeting. I attended and this a quick summary of the notes 
I took at the meeting. 


First a benchmark reported by Inmos: Multivariate regression analysis 


IBM PC 45 minutes 
T800 18 seconds 
T800 x 4 7 seconds 





Inmos also had a T800 powered multiuser flight simulator that kept 4 
people at a time happy shooting each other down. 4 T800’s per user plus a 
T4 graphics card and a load of T2’s handling the joysticks. 











All in an ITEM box together. The graphics animation was VERY smooth, far 
better than a SUN3/260C+fpatgpone flight simulator I have played with. 





Atari and Perihelion have got together so that Perihelion are designing 
the hardware and the software for a high performance workstation to be 
manufactured and sold by Atari. 


Perihelion Hardware 





Perihelion is headed by Jack Lang in Cambridge, England. 





Stage 1 Hardware is a Mega ST add-on system intended for software 
developers. 


Stage 2 Hardware is a compatible single box workstation. 


[The Mega ST is a front end I/O processor only. The block diagram looks 
like: 




















|blitter| | 4 Mb DRAM | 
| Mega ST | | Interface | | T800-20 | | 
| kbd I/O |---| Link Adaptor|----| [pa ee 
| mouse | | SCSI disk | | | | 
| floppy | 
SSeS | | | f |1 Mb VRAM| |Graphics| 
4Mb/s|SCSI | | 
SSS ae 3 ECL buffered 
| 40 Mb | 20 MHz links 
| Winch | 


The box takes up to 16 Mb on the motherboard (using 4Mbit DRAMS) and has 
three expansion slots which can take either 4Mb (1Mbit) or 16Mb (4Mbit) of 
DRAM each for a total in the box of 64 Mb. The expansion slots use a 
single 
DIN plug (VME-type) and the 3 ECL buffered links go onto them so that a 
slot can contain a board with more transputers on it. Size is enough for 
four T800s + 1 Mb each per card. Graphics cards can also be used to 
replace 

the built-in hardware. 














The Blitter 2D fills at 128 Mpixels/sec, 2D block copy at 16 Mpixels/sec. 
(It has a novel architecture based on work by Phil Willis at Bath 
University). 


Graphics modes: 


1280 * 960 * 4 bpp 
1024 * 768 * 8 bpp 

640 * 480 * 8 bpp 2 screens for animation 

512 * 480 * 32 bpp true colour + overlay and tag bits 


60 Hz, not sure about interlace. 
Probably uses Inmos G170 CLUT giving 256K colour shades. 


SCSI disk uses true DMA synchronous SCSI interface to get 4Mbytes/s, 40Mb 
is minimum size. 


A photo of a completed motherboard in box was shown, smaller than an IBM 
PC box with 3 fair sized slots. 


Perihelion Software 





This is based in Shepton Mallet, Somerset, England and is headed by Tim 


King ex of Metacomco, Amigados fame. 


Operating system called Helios written in C to support single processor 
workstations, 4 processor workstations, 1000 processor farms or anything 
in between. 


Helios is distributed, multiprocessor, multiuser, sympathetic to the 
Transputer and familiar to Unix users. Tim King has listened to the 
criticism of Amigados and has avoided a lot of the complaints about that 
system. 


It is based on message passing with transparent passing across processors, 
it uses a client/server model, has per-processor protection and capability 
based access. 





Networking and diskless workstations will be supported via the 3 ECL 
buffered links with no extra hardware. 








Applications can be written in 3 modes, the traditional single threaded 
program, unix-like multiple processes at a coarse grain level or parallel 
algorithms using a medium grain level. Existing TOS/GEM applications can 








run on the Mega ST front end processor. 


User Interface 

X-11 window system standard. 

GEM - translating GEM traps on the 68K i/o proc to the T800. 
GEM running under X-11 may be provided. 

Standard unix like shell command line interface. 








Compatibility 

MSDOS floppy disk format 

UNIX (TM) hard disk format 
UNIX (TM) compatible C library 
UNIX (TM) command subset 





Languages 
C Pascal Lisp 
Fortran BCPL Occam 


Development Tools 


Hosted on ST or Unix(TM) or MSDOS or native 


Asm/link 
C 
Debugger 


Atari’s Position 


They are looking for wider markets and will go upmarket into workstation 
technology. The hardware design will be Atari’s property but Helios is 
already spreading wider, another 4 companies are likely to use it so far. 








It will be launched at COMDEX as a Mega ST add-on for developers. 
Development systems available in Dec 87/Jan 88. The standalone system will 





be launched at Hannover in March 88. Product in the shops in June 88 in 
the UK. Product in Europe 6 months later and US launch June 89, giving a 
years head start to the UK software developers and a chance for the 
machine 

to gather some applications software before it hits the US. 





Priced well below Mac II,base level entry price (no winchester or monitor) 
aimed at 1000 pounds according to Jack Lang. 


For now they will provide a set of 3 manuals, User Manual, Developers 
Manual and Technical Manual for 50 pounds, you then become a registered 
developer and get a priority place in the queue for developers hardware 
in December. 








Apply for more information to: Perihelion Software Limited 
24 Brewmaster Buildings 
Charlton Trading Estate 
Shepton Mallet 
Somerset BA4 50 
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ATARI SHOW! 


T] 





THE FIRST CANADIAN ATARI USER CONVENTION 

















NOVEMBER 06, 1988. 











This is CANADAS first and only Atari user convention this year. This 
convention is staged and sponsored by "THE TORONTO ATARI FEDERATION" 

user group. This group maintains 500 members both in the TORONTO/ONTARIO 
CANADA area and across the country as well as having associate members 
from around the world. We have a 40 mb 24hr BBS 416-235-0318 available. 
It has everything anyone would require when using ATARI SYSTEMS. If 
anyone wants more info on the computer show leave a message on the board 
and we will be in touch. If this is not convenient contact the people 
listed below. 























This unique computer show is dedicated exclusively to ATARI 
COMPUTER SYSTEMS.This exciting new event promises to be jam packed with 
information, demonstrations, lectures and hands on work shops. One of the 
main exhibitors will be Atari Canada, showing off all the latest software 
as well as its new and innovative products. That’s not all, there will be 
lots of retailers selling their wares as Special Low Convention prices, 
hardware and software manufacturers displaying their latest products, user 
groups demonstrating Atari products and selling their PD software disks, 
lectures by knowledgeable speakers, seminars by prominent developers and 
even hands-on workshops where the registered participants can actually 


























work on projects under the guidance of an expert. There will be something 
for everyone. From multi-player adventure games on the 8-bit to business 
applications for the Atari IBM clones. So, if you are an Atari owner, or 


plan to be one or just looking for information, this is the place you 
will want to be. 








HE FIRST CANADIAN ATARI USERS CONVENTION is being held at THE SKYLIN 
TRIUMPH HOTEL located just off highway 401 on Keele Street. 





Ct] 
































NOVEMBER 6TH, 1988 from 10:00am to 6:00pm. 





(Special hotel rates available) Phone:1-800-268-1332. 


For more information contact: 











PRESS: (Mike Searl) .......... 416/245-5543 
EXHIBITORS: (Jim Jorritsma)...416/242-3413 
PUBLIC “INF O* EVLNEE S os maa paai 416/425-5357 
TAF ONLINE BBS (24hr)......... 416/235-0318 





or, Call: Jim Clark, President, Toronto Atari Federation 416/928-1143 





For more information send all inquiries to: 





"TORONTO ATARI FEDERATION" 
Computer Show 
5334 Yonge ST. 
1527 WILLOWDALE, ONTARIO CANADA M2N 6M2 
































The following is from one of the major online services, we felt it held 
enough significance to be reprinted here. The staff of ST Report is 
withholding comment on the following matters. 








31-AUG 06:55 General Information 
RE: Mega/Federated (Re: Msg 6064) 
From: NEILHARRIS To: MADMODIFIER 











The service idea for Federated is to start with service on a district 
basis (covering up to 8 stores) and adding more facilities as volume 
warrants. 





Because the stores within a district are close enough together, turnaround 
will still be minimal -- trucks will be going between the stores daily. 





This is precisely how the existing regional chains do their service. We 
can’t expect a chain of stores to make the capital investment in a full 
repair facility for each location right up front. 


As far as outside sales goes, that, too, is in the works for Federated. 
And from what I have seen, it is likely that the sales efforts from 
Federated could be more serious than the lip service some dealers pay to 
outside sales. 


Lloyd, getting off the specifics to the general -- the reason we tend to 
ignore posts like your diatribe (and lately that’s what you have been 
leaving) is because, no matter what move Atari makes, it causes a storm of 


criticism. You would think that based on the critics, all was fine with 
the ST market two years back and all the moves since then have been 
causing the problems. From where I sit, the market was going in the wrong 
direction then, and efforts have been made (and are continuing to be made) 
to establish the ST. 


Furthermore, these efforts are being undermined by a group of people who 
take perverse pleasure in tearing down what we are trying to build up. 
Lloyd, you are not even active on CIS, so I doubt you were included in the 
"gang" label. Why are you so anxious to join the club? Is it a badge of 
honor? 





People seem to think we have no plans for future machines. That could not 
be farther from the truth. There are some good moves being made up in 
engineering. Good people have been brought in to get the work done. But 
the user community doesn’t seem to want to give them a chance. It is a 
terrible situation to be in. The reaction here in Sunnyvale is to pull 
away from the online areas and from the community in general, because all 
we get is abuse which we cannot counter because we cannot reveal our new 
products prematurely. 





From my personal perspective, I am still fighting. Much of the user 
support and communications efforts in the last few years have been my 
doing. For a while, it looked like there was going to be a close 
relationship between Atari and the users. Now, it looks bleak for that 
prospect. 





Back to the marketplace. "Rex" seems to think mail order is the answer. 
Lloyd likes the dealers. From inside the company, we feel very strongly 
that dealers are the answer, from solid evidence that sales dropped 
steadily as the product moved into mail order. We have made moves to 
cement relationships with dealers, which many dealers have appreciated and 
reacted to favorably. 














As to Federated, well, it is certainly a bit of a mess that needs to be 
fixed. But in the few weeks I have been involved with it, I see a lot of 
potential. At the very least, it brings the focus here much much closer 
to the "front lines" of the marketplace, where lessons can be learned that 
will profoundly influence the future direction of the company. 














Furthermore, there is good potential to develop a group of full-service 
stores catering to the entire Atari line (and more, of course). 8-bit 
sales through Federated have been strong, and we’re looking at expanding 
that line. What other dealer could have brought that off? 





To reiterate the main point from above, every time we make a move there is 
a storm of criticism, much of it from out of left field. Only time will 
tell, and if those of us here who are actually fighting the war can stick 
it out despite all this, I think the outcome will be what we all want —- a 
robust, thriving line of quality, inexpensive computers. 











—-->Neil 


31-AUG 06:59 General Information 
RE: The Future of TOS 
From: NEILHARRIS To: ALL 











Without getting specific in any way, here is a message for everyone: 


TOS has a future. 


This information comes after chats with the engineers to find out what 
they’re up to, and with top management here to determine our own level of 
commitment. 





TOS has a future. 


—-->Neil 


31-AUG 21:57 General Information 
RE: Mega/Federated (Re: Msg 6100) 
From: MADMODIFIER o: NEILHARRIS 

















Neil, 


I want to thank you for your reply, it was appreciated. And no, I’m 
not really interested in being ’one of the gang of five’, but I was told 
that I had been included as one of the ’gang’. And I don’t feel that I 
‘bash’. 


When you guys do something right, I tell you so. But when *I feel* that 
you are doing something wrong, I’m going to tell you that also. Now let 
me give you my side.......... 


1) I don’t really care about mail-order. I think you could allow 
mail-order stores to carry the 520 but it’s not that important to me one 
way or the other. 


2) I find that Atari seems to have two sets of rules..one for the 
independent stores and another for Federated. Why were the independent 
dealers *required* to be service centers but not the Federated stores? My 
local dealer was told (and I think he has it in writing) that NO stores 
locally would be allowed to carry the Mega/Laser unless they had a 
complete service center. But you don’t enforce that rule when it comes to 
Federated. 

















3) I understand about district servicing....but couldn’t the 
independents have been allowed the same thing? Two or three local stores 
would have liked to have carried the Mega/Laser but couldn’t because they 
didn’t have service centers in their store. BUT they all could have got 
together with the one that did have a local store and formed a ’/district 
service center’....but they weren’t allowed that option. 

















4) I think you (and Atari) have a higher regard for the Federated name 
than the common person/businessman. The vast majority of the people I 
know, think that Federated is almost a joke. Yes, they'll go there to buy 
a stereo/tv when they’re on sale, but they’d never rate Federated as a 
‘quality’ store. 











5) I have no qualms about allowing Federated to carry the ST line. I 
just believe the independent dealers should be given the same breaks that 
Federated gets. Told about specials at the same time, etc. This has NOT 
happened in the past. Radio Shack for years had company stores and 
independently owned stores and both got along with no problems (most of 
the independent dealers got rich). But they only had ONE set of rules for 
both....not two. 




















6) I’ve seen and talked to Federated employees that have been to your 
seminar. Before the seminar they were horrible, now they’re just simply 
bad. 


7) I feel (my opinion) the worse thing that Atari could do would be to 
stop supporting the online services. The ST owners are leary of Atari the 
way it is, if there were no communications (and that’s what there would 
be....) between the two groups, you’d be in worse shape than you are 
now. 


8) Finally, look at things from our perspective. We’ve heard promises 
about changes from Atari for almost three years now....and have seen very 
few changes (from a users standpoint). We’re still waiting for the CD 
Roms, IBM hardware emulator, PC clones, etc. You tell us that there are 
new great and glorious things in the works...that’s great, but we haven’t 
seen a lot of the past great and glorious things that were promised yet. 
There’s still no national advertising and by reading between the lines in 
Sam’s post (i.e. dram shortage will continue until lst part of next year), 
there won’t be any national advertising this year. In three years there 
has been no upgrades to the o/s (the Mega roms don’t count...if it hadn’t 
been for the blitter chip, they would have never came out. And 97% of the 
people can’t get them anyway). Yes, I know about the new roms (and I’ve 
got a current version)....but there’s no upgrade to them. Atari simply 
fixed some bugs that should have been fixed 2 years ago and made some 
cosmetic changes (a item selector like CFJ’s, show the program/folder 
names during file transfer, etc.). But nothing major....no support for a 
68020, no support for 32-meg partitions, etc. 











Neil, the average Atari owner feels like the proverbial mushroom, 
(kept in the dark and covered with manure), so there is a reason that we 
get ’antsy’ at times. Every once in a while we get a pat on the head 
to pacify us, but nothing substantial (still no blitter for the ST’s). 











I hope this post wasn’t a diatribe. I’ve tried to be calm and 
rational....giving you my reasons for why I say what I do. I’m on tons of 
local BBS’s across the country (I’m a BBS addict) and a LARGE percentage 
of ST owners feel even more strongly than I do. It’s up to Atari to open 
up and calm it’s users, not me. We need more open communications between 
Atari and the user base. The "We can’t talk about that yet" gets old 
after 6-8 months. We never hear or have any open communication with 
Atari, so it’s no wonder that we start listening to every rumor that 
comes down the pike. 




















Lloyd E. Pulley, Sr. 





ANTIC PUBLISHING INC. 
COPYRIGHT 1988 
REPRINTED BY PERMISSION. 

















Professional GEM by Tim Oren 
Column #2 -— Windows, part 2 











EXCELSIOR! 











In this installment, we continue the exploration of GEM’s window 
manager by finding out how to process the messages received by an 
application when it has a window defined on the screen. 





Also, beginning with this column, sample C code demonstrating the 
techniques discussed will be available on SIG*ATARI in DL5. This will 
allow you to download the code without interference by the CIS 
































text-formatter used by ANTIC ONLINE output. The file for this column 
is GEMCL2.XMO. All references to non-GEM routines in this column 
refer to this file. Please note that these files will not contain 
entire programs. Instead, they consist of small pieces of utility 


code which you may copy and modify in your own programs. 


REDRAWING WINDOWS 








One of the most misunderstood parts of GEM is the correct method 





for drawing within a window. Most requests for redrawing are 
generated by the GEM system, and arrive as messages (read with 
evnt_multi) which contain the handle of the window, and the screen 





rectangle which is "dirty" and needs to be redrawn. Screen areas may 
become dirty as a result of windows being closed, sized down, or 
moved, thus "exposing" an area underneath. The completion of a 
dialog, or closing of a desk accessory may also free up a screen area 
which needs to be redrawn. When GEM detects the presence of a dirty 
rectangle, it checks its list of open windows, and sends the 
application a redraw message for each of its windows which intersects 
the dirty area. 











CAVEAT EMPTOR 








GEM does not "clip" the rectangle which it sends to the 
application; that is, the rectangle may not lie entirely within the 
portion of the window which is exposed on the screen. It is the job 
of the application to determine in what portion of the rectangle it 
may safely draw. This is done by examining the "rectangle list" 
associated with the window. A rectangle list is maintained by GEM for 
each active window. It contains the portions of the window’s interior 
which are exposed, i.e., topmost, on the screen and within which the 
app may draw. 














Let’s consider an example to make this clear. Suppose an app has 
opened two windows, and there are no desk accessory windows open. The 
window which is topmost will always have only one rectangle in its 
list. If the two are separate on the screen, then the second window 
will also have one rectangle. If they overlap, then the top window 
will "break" the rectangle of the bottom one. If the overlap is at a 
corner, two rectangles will be generated for the bottom window. If 
the overlap is on a side only, then three rectangles are required to 
cover the exposed portion of the bottom window. Finally, if the first 
window is entirely within the second, it requires four rectangles in 
the list to tile the second window. 


























Try working out a few rectangle examples with pencil and paper to 
get the feel of it. You will see that the possible combinations with 
more than two windows are enormous. This, by the way, is the reason 
that GEM does not send one message for each rectangle on the list: 
with multiple windows, the number of messages generated would quickly 
fill up the application’s message queue. 























Finally, note that every app MUST use this method, even if it only 
uses a Single window, because there may be desk accessories with their 
own windows in the system at the same time. If you do not use the 
rectangle lists, you may overwrite an accessory’s window. 





INTO THE BITS 


T 





First, we should note that the message type for a redraw request is 
WM_REDRAW, which is stored in msg[0], the first location of the 
message returned by evnt_multi. The window handle is stored in 
msg[3]. These locations are the same for all of the message types 
being discuss. The rectangle which needs to be redrawn is stored in 
msg[4] through msg[7]. 











Now let’s examine the sample redraw code in more detail. The redraw 
loop is bracketed with mouse off and mouse on calls. If you forget to 
do this, the mouse pointer will be over-written if it is within the 
window and the next movement of the mouse will leave a rectangular 
blotch on the screen as a piece of the "old" screen is incorrectly 
restored. 














The other necessary step is to set the window update flag. This 
prevents the menu manager from dropping a menu on top of the screen 
portion being redrawn. You must release this flag at the end of the 
redraw, or the you will be unable to use any menus afterwards. 





The window rectangles are retrieved using a get-first, get-—next 
scheme which will be familiar if you have used the GEM DOS or PC-DOS 








wildcard file calls. The end of the rectangle list has been reached 
when both the width and height returned are zero. Since some part of 
a window might be off-screen (unless you have clamped its position - 





see below), the retrieved rectangle is intersected with the desktop’s 
area, and then with the screen area for which a redraw was requested. 





Now you have the particular area of the screen in which it is legal 
to draw. Unless there is only one window in your application, you 
will have to test the handle in the redraw request to figure out what 
to put in the rectangle. Depending on the app, you may be drawing an 
AES object tree, or executing VDI calls, or some combination of the 
two. In the AES case, the computed rectangle is used to specify the 
bounds of the objc_draw. For VDI work, the rectangle is used to set 
the clipping area before executing the VDI calls. 

















A SMALL CONFESSION 





At the beginning of this discussion, I deliberately omitted one 
class of redraws: those initiated by the application itself. In some 
cases a part of the screen must be redrawn immediately to give 
feedback to the user following a keystroke, button, or mouse action. 
In these cases, the application could call do_redraw directly, without 
waiting for a message. The only time you can bypass do_redraw, and 


draw without walking the rectangle list, is when you can be sure that 
the target window is on top, and that the figure being drawn is 
entirely contained within it. 


In many cases, however, an application initiated redraw happens 
because of a computed change, for instance, a spreadsheet update, and 
its timing is not crucial. In this instance, you may wish to have the 





app send ITSELF a redraw request. 





The main advantage of this approach is that the AES is smart enough 
to see if there is already a redraw request for the same window in the 
queue, and, if so, to merge the requests by doing a union of their 
rectangles. In this fashion, the "blinky" appearance of multiple 
redraws is avoided, without the need to include logic for merging 
redraws within the program. 


A utility routine for sending the "self-redraw" is included in the 
down-load for this article. 





WINDOW CONTROL REQUESTS 

















An application is notified by the AES, via the message system, when 
the user manipulates one of the window control points. Remember that 
you must have specified each control point when the window was 
created, or will not receive the associated control message. 

The most important thing to understand about window control is that 
the change which th user requested does not take place until the 
application forwards it to the AES. While this makes for a little 
extra work, it gives the program a chance to intervene and validate or 
modify the request to suit. 














A second thing to keep in mind is that not all window updates cause 
a redraw request to be generated for the window, because the AES 
attempts to save time with raster moves on the screen. 


Now let’s look at each window control request in detail. The 
message code for a window move is WM_MOVED. If you are willing to 
accept any such request, just do: 














wind_set (wh, WE_CXYWH, msg[4], msg[5], msg[6], msg[7]); 


(Remember that wh, the window handle, is always in msg[3]). 








he AES will not request a redraw of the window following this 
call, unless the window is being moved from a location which is 
partially "off-screen". Instead, it will do a "blit" (raster copy) of 
the window and its contents to the new location without intervention 
by the app. 





There are two constraints which you may often wish to apply to the 
user’s move request. The first is to force the new location to lie 
entirely within the desktop, rather than partially off-screen. You 
can do this with the rc_constrain utility by executing: 


re_constrain(&full, &msg[4]); 


before making the wind_set call. (Full is assumed to contain the 
desktop dimensions.) 


The second common constraint is to "Snap" the x-dimension location 
of the new location to a word boundary. This operation will speed up 
GEM’s "blit" because no shifting or masking will need to be done when 
moving the window. To perform this operation, use align() before the 
wind_set call: 








msg[4] = align(msg[4], 16); 





The message code for a window size request is WM_SIZED. Again, if you 
are willing to accept any request, you can just "turn it around" with 
the same wind_set call as given for WM_MOVED. 














Actually, GEM enforces a couple of constraints on sizing. First, 
the window may not be sized off screen. Second, there is a minimum 
window size which is dependent on the window components specified when 
it was created. This prevents features like scroll arrows from being 
squeezed into oblivion. 


The most common application constraint on sizing is to snap the 
size to horizontal words (as above) and/or vertical character lines. 
In the latter case, the vertical dimension of the output font is used 
with align(). 





Also, be aware that the size message which you receive specifies 
the EXTERNAL dimensions of the window. To assure an "even" size for 
the INTERNAL dimensions, you must make a wind_calc call to compute 
them, use align() on the computed values, back out the corresponding 
external dimensions with the reverse wind_calc, and then make the 
wind_set call with this set of values. 


























A window resize will only cause a redraw request for the window if 
the size is being increased in at least one dimension. This is 
satisfactory for most applications, but if you must "reshuffle" the 
window after a size-down, you should send yourself a redraw (as 
described above) after you make the wind_set call. This will 
guarantee that the display is updated correctly. Also note that the 
sizing or movement of one window may cause redraw requests to be 


generated for other windows which are uncovered by the change. 











The window full request, with code WM_FULLED, is actually a toggle. 
If the window is already at its full size (as specified in the 
wind_create), then this is a request to shrink to its previous size. 
If the window is currently small, then the request is to grow to full 
size. 


Since the AES records the current, previous, and maximum window 
size, you can use wind_get calls to determine which situation 
pertains. The hndl_full utility in the down-load (modified from 
Doodle), shows how to do this. The "zoom box" effects when changing 
size are optional, and can be removed to speed things up. Again, if 
the window’s size is decreasing, no redraw is generated, so you must 
send yourself one if necessary. You should not have to perform any 
constraint or "snap" operations here, since (presumably) the full and 
previous sizes have had these checks applied to them already. 














The WM_CLOSED message is received when the close box is clicked. 
What action you perform depends on the application. If you want to 
remove the window, use wind_close as described in the last column. In 
many applications, however, the close message may indicate that a file 








is to be saved, or a directory or editing level is to be closed. In 
these cases, the message is used to trigger this action before or 
instead of the wind_close. (Folders on the Desktop are an example of 
this situation.) 








The WM_TOPPED message indicates that the AES wants to bring the 
indicated window to the "top" and make it active. This happens if the 
user clicks within a window which is not on top, or if the currently 
topped window is closed by its application or desk accessory. 
Normally, the application should respond to this message with: 


wind_set (wh, WF_TOP, 0, 0); 
and allow the process to complete. 


In a few instances, a window may be used in an output only mode, 
such as a status display, with at least one other window present for 
input. In this case, a WM_TOPPED message for the status window may be 
ignored. In all other cases, you must handle the WM_TOPPED message 
even if your application has only one window: Invocation of a desk 
accessory could always place another window on top. If you fail to do 
SO, subsequent redraws for your window may not be processed 
correctly. 














WINDOW SLIDER MESSAGES 











If you specify all of the slider bar parts for your window, you may 
receive up to five different message types for each of the two sets of 
sliders. To simplify things a little, I will discuss everything in 
terms of the vertical (right hand side) sliders. If you are also 
using the horizontal sliders, the same techniques will work, just use 
the alternate mnemonics. 

















The WM_VSLID message indicates that the user has dragged the slider 
bar within its box, indicating a new relative position within the 
document. Along with the window handle, this message includes the 
relative position between 1 and 1000 in msg[4]. 


Recall from last column’s discussion that this interval corresponds 
to the "freedom of movement" of the slider. If you want to accept the 
user’s request, just make the call: 





wind_set (wh, WF_VSLIDE, msg[4], 0, 0, 0); 





(Corresponding horizontal mnemonics are WM_HSLID and WF_HSLID 


GI 
<~ 


Note that this wind_set call will not cause a redraw message to be 
sent. You must update the display to reflect the new scrolled 
position, either by executing a redraw directly, or by sending 
yourself a message. If the document within the window has some 
structure, you may not wish to accept all slider positions. Instead 
you may want to force the scroll position to the nearest text line 
(for instance). Using terms defined in the last column, you may 
convert the slider position to "document units" with: 








top_wind = msg[4] * (total_doc - seen_doc) / 1000 + top_doc 


(This will probably require 32-bit arithmetic). After rounding off or 
otherwise modifying the request, convert it back to slider units and 


make the WF_VSLIDE request. 





The other four slider requests all shar on messag cod 
WM_ARROWED. They are distinguished by sub-codes stored in msg[4]: 
WA_UPPAGE, WA_DNPAGE, WA_UPLINE, and WA_DNLINE. These are produced by 
clicking above and below the slider, and on the up and down arrows, 
respectively. (I have no idea why sub-codes were used in this one 
instance.) The corresponding horizontal slider codes are: WA_LFPAGE, 
WA_RTPAGE, WA_LFLINE, and WA_RTLINE. 




















T 





What interpretation you give to these requests will depend on the 
application. In the most common instance, text documents, the 
customary method is to change the top of window position (top_wind) by 
one line for a WA_UPLINE or WA_DNLINE, and by seen_doc (the number of 
lines in the window) for a WA_UPPAGE or WA_DNPAGE. 


























After making the change, compute a new slider position, and make 
the wind_set call as given above. If the document’s length is not an 
even multiple of "lines" or "pages" you will have to be careful that 
incrementing or decrementing top_wind does not exceed its range of 
freedom: top_doc to (top_doc + total_doc - seen_doc). If you have 
such an odd size document, you will also have to make a decision on 
whether to violate the line positioning rule so that the slider may be 
put at its bottom-most position, or to follow the rule but make it 
impossible to get the slider to the extreme of its range. 





A COMMON BUG 


It is easy to forget that user clicks are not the only things that 





affect slider position. If the window size changes as a result of a 
WM_SIZED or WM_FULLED message, the app must also update its sliders 
(if they are present). This is a good reason to keep the top of 





window information in "document units". 


You can just redo the position calculation with the new "seen_doc" 
value, and call wind_set. Also remember that changing the size of the 
underlying document (adding or deleting a bottom line, for instance) 
must also cause the sliders to be adjusted. 





DEPT. OF DIRTY TRICKS 








[There are two remaining window calls which are useful to advanced 


programmers. They require techniques which I have not yet discussed, 
so you may need to file them for future reference. 








The AES maintains a quarter-screen sized buffer which is used to 
save the area under alerts and menu drop-downs. It is occasionally 
useful for the application to gain access to this buffer for its own 
use in saving screen areas with raster copies. To do so, use: 








wind_get (0, WF_SCR 


T 


EN, &loaddr, &hiaddr, &lolen, &hilen); 











Hiaddr and loaddr are the top and bottom 16-bits (respectively) of the 
32-bit address of the buffer. Hilen and lolen are the two halves of 























its length. Due to a preculiarity of the binding you have to 
reassembl thes pieces befor using them. (The actual value of 
WF_SCREEN is 17; this does not appear in some versions of the 
GEMDEFS.H file.) 











If you use this buffer, you MUST prevent menus from dropping down 
by using either the BEG_UPDATE or BEG MCTRL wind_update calls. 
Failure to do so will result in your data being destroyed. Remember 
to use the matching wind_update: END_UPDATE or END_MCTRL, when you are 
done. 





























The other useful call enables you to replace the system’s desktop 
definition with a resource of your choosing. The call: 





wind_set (0,WF_NEWDESK, tree, 0,0); 











where tree is the 32-bit address of the object tree, will cause the 
AES to draw your definition instead of the usual gray or green 
background. Not only that, it will continue to redraw this tree with 





no intervention on your part. Obviously, the new definition must be 
carefully built to fit the desktop area exactly or garbage will be 
left around the edges. For the truly sophisticated, a user-defined 


object could be used in this tree, with the result that your 
application’s code would be entered from the AES whenever the desktop 
was redrawn. This would allow you to put VDI pictures or complex 
images onto the desktop background. 





A SIN OF OMISSION 








In the last column, I neglected to mention that strings whose 
addresses are passed in the WF_NAME and WF_INFO wind_set calls must be 
allocated in a static data area. Since the AES remembers the 
addresses (not the characters), a disaster may result if the storage 





has been reused when th window manager next attempts to draw the 
window title area. 


COMING SOON... 





This concludes our tour of GEM’s basic window management 
techniques. There have been some unavoidable glimpses of paths not yet 
taken (forward references), but we will return in time. 








On our next excursion, we will take a look at techniques for 
handling simple dialog boxes, and start exploring the mysteries of 
resources and object trees. 


>> >>> >>> >> >>> >>> >> >>> >> >>> Sample Redraw Code 
KKK KK KK KKK KKK KK KK KK <<< 





VOID 

do_redraw(wh, area) /* wh = window handle from msg[3] */ 
WORD wh; /* area = pointer to redraw rect- */ 
GREC xarea; JE tangle in msg[4] thru msg[7] */ 
{ 
GREC box; 











graf_mouse(M_OFF, Ox0L); 
wind_update (BEG_UPDATE) ; 








wind_get (wh, WF_FIRSTXYWH, &box.g_x, &box.g_y, &box.g_w, &box.g_h); 
while ( box.g_w && box.g_h ) 
{ 
if (rc_intersect (full, &box) ) /* Full is entire screen */ 
if (rc_intersect (area, &box)) 
{ 
if (wh == wl_handle) /* Test for window 1 handle */ 
{ /* AES redraw example */ 
objc_draw(wl_tree, ROOT, MAX DEPTH, box.g_x, 
box.g_y, box.g_w, box.g_h); 














} 

else if (wh == w2_handle) /* Test for window 2 handle */ 
{ /* VDI redraw example */ 
set_clip(TRUE, &box); 
/* Put VDI drawing calls here */ 
} 

/* add more windows here */ 

} 

wind_get (wh, WF_NEXTXYWH, &box.g_x, &box.g_y, &box.g_w, 
&box.g_h); 








wind_update (END_UPDATE) ; 
graf_mouse(M_ON, Ox0L); 
} 








>> >>>>>>>>>>>>>>>>>>>>>>> Utilities used in do_redraw 
OC CCCCCCCCCCCCCCCCCCCCE< 





VOID 
set_clip(clip_flag, area) /* set clip to specified area ao, 
WORD clip_flag; 
GRECT xarea; 
{ 
WORD pxyl4]; 





grect_to_array(area, pxy); 
vs_clip(vdi_handle, clip_flag, pxy); 
} 



































VOID 
grect_to_array(area, array) /* convert x,y,w,h to upr lt x,y and 
Af 

GRECT xarea; Ae lwr rt x,y */ 

WORD *array; 

{ 

*array area->g_x; 

*array area->g_y; 

*array area->g_x + area->g_w 1; 

*array area->g_y + area->g_h 1; 

} 

WORD 
rc_intersect (pl, p2) /* compute intersect of two rectangles 
Ai, 

GRECT *pl, *p2; 

{ 

WORD tx, ty, tw, th; 











tw = min(p2->g_x + p2->g_w, pl->g_x 4 
th = min(p2->g_y + p2->g_h, pl->g_y 4 
tx = max(p2->g_x, pl->g_x); 

ty = max(p2->g_y, pl->g_y); 

p2->g_x = tx; 

p2->g_y = ty; 

p2->g_w = tw - tx; 

p2->g_h = th - ty; 

return( (tw > tx) && (th > ty) ); 


} 


>>>>>>>>>>>>>>>>>>>>>>>>> 


<<< <<< KKK KKK 








VOID 
send_redraw(wh, p) 
WORD wh; 
GRECT *p; 
{ 
WORD msg[8]; 
msg[0] = WM_REDRAW; 
msg[1] = gl_apid; 
msg[2] = 0; 
msg[3] = wh; /* Handle 
msg[4] = p->g_x; 
msg[5] = p->g_y; 
msg[6] = p->g_w; 
msg[7] = p->g_h; 
appl Pee apid, 16, &msg); 


Ai, 


/* Defined in GEMBIND.H 
/* As returned by appl_init */ 


/* Use ADDR (msg) 


t pl->g_w); 
t pl->g_h); 


"Self-redraw" Utility 





#7 


of window to redraw */ 


for portability 


>>>>>>>>>>>>>>>>>>>>>> Utilities for Window Requests <<<<<<<<<<<<<<<<<<<< 



































VOID 
rc_constrain(pc, pt) 
GREC ADC} 
GREC pE 
{ 
if (pt->g_x < pc->g_x) 
pt->g_x = pc->g_x; 
if (pt->g_y < pc->g_y) 
pt->g_y = pc->g_y; 
if ((pt->g_x + pt->g_w) > (pc->g_x + pc->g_w)) 
pt->g_x (pc->g_x pc->g_w) - pt->g_w; 
if ((pt->g_y + pt->g_h) > (pc->g_y + pc->g_h)) 
pt—>g_y (pc->g_y + pc->g_h) - pt->g_h; 
} 
WORD 
align (x,n) /* Snap position x to an n-bit grid * / 
WORD Xj. “nh? /* Use n = 16 for horizontal word alignment */ 
{ 
x += (n >> 2) - 1; /* Round and... */ 
x=n* (x / n); /* remove residue */ 
return (x); 


>>>>>>>>>>>>>>>>>>>>>>>>> Window full utility <<<<<<<<<<<<<<<<<<<<<<<<<< 
































VOID 
hndl_full (wh) /* depending on current window state, make window 
*/ 
WORD wh; /* full size -or- return to previous shrunken size 
*/ 
{ /* graf_ calls are optional special effects. AY 
GREC prev; 
GREC Curr; 
GREC full; 
wind_get (wh, WF_CXYWH, &curr.g_x, &cCurr.g_y, &curr.g_w, &curr.g_h); 
wind_get (wh, WF_PXYWH, &prev.g_x, &prev.g_y, &prev.g_w, &prev.g_h); 
wind_get (wh, WF_FXYWH, &full.g_x, &full.g_y, é&full.g_w, &full.g_h); 
if ( rc_equal(é&curr, &full) ) 
{ /* Is full, change to previous * / 
graf_shrinkbox(prev.g_x, prev.g_y, prev.g_w, prev.g_h, 
full.g_x, full.g_y, full.g_w, full.g_h); 
wind_set (wh, WF_CXYWH, prev.g_x, prev.g_y, prev.g_w, prev.g_h); 
/* put send_redraw here if you need it */ 
} 
else 
{ /* is not full, so set to full k 
graf_growbox(curr.g_x, curr.g_y, curr.g_w, curr.g_h, 
full.g_x, full.g_y, full.g_w, full.g_h); 
wind_set (wh, WF_CXYWH, full.g_x, full.g_y, full.g_w, full.g_h); 
} 
} 
WORD 
rc_equal (p1, p2) /* tests for two rectangles equal X, 
GRECT *pl, *p2; 





{ 

if ((pl->g_x != p2->g_x) || 
(p1->g_y != p2->g_y) |l 
(p1->g_w != p2->g_w) || 
(pl->g_h != p2->g_h) 

return (FALSE) ; 
return (TRUE) ; 
} 


) 








Next Week, #3 in the ongoing series........... 
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GOOD TIMES AHEAD? 











by T."Rex Reade 





Here I sit, staring at th quipment before me saying to myself, "Self, 
why do you carry on with the folks at Atari like you do and when are you 
going to realize that those who give the most rediculous answers and 
replies are the lowest on the totem pole? Well, today I answered that 
question and by golly, I realized that the TOP BRASS at Atari want the 
same things I do! It’s the turkeys that are making all the problems in 
the rumor mill and hard feelings department. Therefore, from now on, Self 
is going to fly with the Eagles and let the turkeys roast themselves. 
Also, a concentration on the positive aspects of Atari will prevail if at 
all possible. 























An important point to make is Atari has a super good concept in the ST 

















computer line and a very weak approach to national marketing. It 

has been said by a few that I favor the mail order houses...in a way I do 
and my reason is very simple...there are some dealers who relish charging 
LIST PRICE for the Atari products....at least mail order stopped the 
gouge...I know of one dealer who is charging 500.00+ for the older (used) 
$c1224...he tells folks that the newer monitors are junk compared to the 
older models..(He offers the new stylish monitor for 100.00 as long as the 
older one has the box and booklets in his trade-in upgrade deal..cute???) 
This appears sleezy and detremental to Atari’s good name! Others are 





very busy trying to market multi-sync monitors which is ok as it stands.. 
but when a "dealer" tries to tell folks it is as good as the SC1224...that 
dealer needs a "Slap!" The SC1224 is a fine RGB monitor and will 
outperform 99% of what is out there in it’s class. We all know 
the multi-syne is a nice space saver but, it’s a compromise on quality in 
"certain areas" like text in medium resolution....it is not even close to 
the quality of the SC1224. The "pin cushion" effect on the multisync was 
more than evident, the SC1224 was just dandy. 








When the dealers resort to wholesale snake oil sales it is time to rethink 
the entire program and we believe that is just what Atari is doing....the 
area representatives do not, as a whole, keep their appointments. The 
exisiting dealers feel neglected thus, they carry on with the attitude 
that Atari doesn’t care about them, so...let’s milk it for all it’s 

worth. The Federated thingy that Neil is trying to polish and groom may 
just be the answer! Company stores through out the Nation, centralized 
service centers with pick up and delivery to company stores in that hub, 
an outside sales force dedicated to commercial sales and application. 





Folks, I do not think this is a pipe dream, this IS coming down the road. 
It has to, in order to save the userbase we have and build upon it. There 
are some very FINE dealers out there who will become a part of the Atari 
chain of stores and this is good....the time has come for sure, to 

eliminate the charletans and snake oil merchants from the ranks of good 


dealers representing Atari. 














One of the really nice things about encouraging folks to send in their 
experiences with dealers (good or bad) is the diversification of opinions 
we receive. Without risking real outcry, it is safe to say, Atari is on 
the right track in trying to establish a national chain as long as the 
GOOD dealers are assured of being treated equally and on the same footing 
as the "company stores". Neil Harris may be many things, but one he will 
do is try his best to make sure the independents (deserving) get a fair 
shake throughout the entire big picture. 


When we hear about bashing and the gang of five and all the other colorful 


non-sense, 
any of this! 


Atari who are in 


know there are al 


we think of hard feelings and emotion. 


a position to bring about change and improvement. 
lways those who, 





There is no reason for 


If one were to really step back and take a long hard look at 
what the majority of the bashers have been doing, 
out the shortfall 


it’s simple! 
and using any means to obtain the attention of 


Pointing 
those at 
As we 
in their BLIND faith and hero worship, 


will defend any premise brought forward by an outspoken person or by an 


individual who may disagree with one or more critics. 
are the folks who have unwittingly perpetuated the SILLY arguments. 


these 
The 


Seemingly, 


Time has come TO ALLOW ATARI the opportunity to SHOW ALL OF US their 


stuff. 
release 


Comdex is right 
(hopefully they 
say we would be proud of 
during the SPRING COMDEX? WE...... shall see. 


around the corner, the new ROMs are due for 

read more than l6mb per partition), and they did 
the advertising this year....remember the CO 

In any case, the 











time is at 











hand to demonstrate to all that our support for Atari has not waivered. 
Nor has any of our faith in JACK TRAMIEL been eroded. 
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Our favorite company may be headed for a very nice 
bonus..Seems the folks at Federated "lost" 43 million 
somewhere in the offering...penalties could double the 
amount for Atari. 





The "Mega4 Deal" is over and now the Mega 2 deal is 
here! After Labor Day, Dealers will be offering 

the Mega2 at a very good price....less than 1395.00... 
certain dealers wanted this kept hush-hush..another 
reason why the ads are so very neccessary. 





Hayes Micro, has been inundated with a super positive 
response for its special Sysops modem discount offer. 
Delivery time is hovering around three to eight weeks. 


ABCO Hard Disks announced the new 130mb Hard Drive 
System is highly successful and like it’s predecessors 
it is fully upgradable. 





The New TOS in ROM chips are expected to be shipping 
and in good supply....it’s nice to see Atari "ON TIME! 


GI 








Latest ST Xformer News 








File Transfer Service 





Using the ST with Atari 810 and 1050 disk drives!! 





by Darek Mihocka 


Users of the ST Xformer II emulator are familiar with methods of 
transfering 8 bit software to the ST. Using modems, null modem 
cables, and 5 1/4" ST drives (with the Xformer File Xfer Program), 
it is possible to transfer over files and most boot disks for 

use with the emulator. 


I am pleased to announce the development of an interface for the 
ST, that allows 8 bit peripherals like the 810, 1050 and XF551 disk 
drives to connect directly to the 520/1040/Mega ST. Other devices, 
like the 850 interface, modems, and printers can also be connected. 
Everything just plugs in, so no warranties have to be voided. 





Using a new version of ST Xformer II not yet released, it is 
possible to boot directly from these drives, thus allowing copy- 
protected commercial software to run under the emulator, and 
eliminating the hassles of the other methods. Now run Text Wizard, 
B/Graph, Visicalc, APX and Antic disks and many more. This opens 
new doors to the world of 8 bit emulation. Also, the new 

Xformer II runs on 512K, something the regular Xformer II can’t do. 








But that’s not all! Users of the ST who are not particularly 

interested in emulation because they still parts of an 8 bit 

system will also find this useful. This interface allows for file 
transfers between the 8 bit drives and the 3 1/2" drives, thus allowing 
easy movement of files back and forth without the need of null modem 
cables or the 850 interface. 





So if you have a 520ST with a single disk drive, and were considering 
buying another drive, consider getting the less expensive 1050 or 
XF551 drives instead of an ST drive. 


Users who do not own an 8 bit disk drive, but who can still borrow 
one for a few days and get their hands on their user group’s 8 bit 
library of disks, will be able to copy them to the ST in as little 
time as it takes to copy the disks normally. 


Although I do not plan to develop this feature unless there is 
specific demand, it is possible to reverse roles and allow the 
Atari 400/800 computers to access the ST as a virtual disk drive, 
thus allowing, for example, a BBS running on an Atari 800 to access 
a 520ST as a large RAMdisk. 





I will produce the interface, and sell it for about $20 to $30. 

One of the reasons that kept me from developing this earlier is 

that I originally wanted the emulator to remain software-only. 

It will remain this way for users without access to 8 bit peripherals, 
but for those users who have access to both systems, this is a 

low cost add-on to increase their enjoyment of their ST. 





At this time, I am unable to predict how long it will take make this 
available to all ST users. Hopefully only a few months. Right now the 
biggest stumbling block is finding those 13 pin 8 bit serial I/O 
connectors, which seem to be very scarce. Dealers and distributors 
interested in carrying this product should contact me by voice. 


Anyone interested in buying one, please phone or write, so that I 
will know how many interfaces to initially produce. 








File transfer service 





Any Xformer users who are finding it difficult to port software over, 
either due to a lack of a modem or null modem cable, should phone me 
about arranging to send me their disks to copy over to the 3 1/2" 
format. With my prototype interface, I can copy hundreds of disks a 
day, and all I require is that you pay for the postage and disks. 


I would be especially interested in obtaining a large database of 
public domain 8 bit software (a user group library?). 


Other Xformer news 


Other improvements are being made to the Xformer. I am working 

out the details of the full speed emulator, which is now on the 
horizon. However, I fell that I will prevent me from devoting further 
time to the Apple and C64 emulators, which have been pretty neglected 
so far, so I will be making the entire source code to ST Xformer II 
available. It is written in Laser C, so only Laser C users will be able 
modify it unless they convert it to another language first. Any 
developers interested in further improving the Apple and Commodore 
emulators will then be able to do so. 














Sometime later in September, I will be putting up the Xformer support 
BBS, to allow modem users without access to Compuserve, Delphi, or 
Genie to call and download the latest emulator and 8 bit files. The 
number will be the same as the current voice number, and operate from 
around midnight to 6am EST/EDT. 





























Finally, if you are a user of ST Xformer II and have not yet registered 
your copy, please do so by sending your name, mailing address, phone, 
and a $20 money order. You will receive a manual and an updated version 
of the software and 8 bit files. Please indicate whether you want the 
regular double sided version of Xformer II, or the 512K single sided 
version of Xformer Junior. 





The address is: 
Darek Mihocka 
310-D Bluevale St. N. 
Waterloo, Ontario N2J 4G3 
CANADA 


In the US, remember that postage for Canada is about 5 cents more. 


The Xformer hotline, voice, and soon by modem, is (519)-747-0386. 


Other sources of ST Xformer 2.10: 








Compuserve - go to the ATARIDEV SIG and enter DL 5 (the Xformer 
SoS sSa = download library) 





Delphi - go the ST LOG SIG by 





typing "gr st" at the main menu. 


== Enter the libraries with the "da" command. 


Genie - go to the Atari ST roundtable by typing "m 475;3" and 
sares download files #7651 thru #7654. 














and, various ST bulletin boards across the country. 








THIS WEEK’S QUOTE: 














"A PAT ON THE BACK IS ONLY A FOOT FROM A KICK IN THE BUTT!" 





T 
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